设计目标
P0 需求
P0的目标主要是把异步微服务整个架构搭起来，消息的结构做的更加通用易于拓展，灰度管理完善以及服务的部署简化。
- 日志加一个 request_id 字段存储 web 服务的 request_id，另外，有一个 local_request_id 标识本次请求。这样方便把整个流程串起来。
- 推送服务集成到微服务内，不再单独部署，补发和补推的脚本废弃，也都集成到微服务里处理。
- 序列号校验，不再要求 web 服务提供回调函数，只需要一个回调接口即可，另外通过在 subscription 配置 check_url，提供默认不需要校验的选项。
- 在实践中发现逐条补发的性能不好，因为排序靠后的消息会因为需要补发前面的消息而反复被补发，因此修改推送方请求补发的逻辑，一次请求完整的补发。这样虽然单次补发变多，整体的性能反而变好。
- 新增订阅不再补推新增前已发的消息。
- 现有的被推送接口设计受限于资源，相同资源的必须相同接口，后续消息的分发在微服务内实现，无需被推送接口做过滤兼容。
- 限制补发和补推的时间，比如限制在24h内。
- 消息的灰度仍采用目前在 cookie 内提供 group_id 的方式。我们这个异步微服务本身的灰度通过队列名中加版本号的形式进行消息隔离订阅来灰度，需要 rmiclient 支持。
- 去掉推送接口 GET 和 POST 可选，统一使用 POST。
- 消息不再按照订阅关系走，而是按照对象走，因为我们在使用这一版异步服务的时候发现，有时候会因为某一个消息卡住或者死锁之类的故障阻碍后续的消息消费。改变消息在队列中的结构可以解决这个问题，不同对象的消息理应不互相依赖。
- 订阅模式统一改成 tag 的形式，逻辑上和 rabbitmq 的 topic 模式一致。
- 消息结构内预留增量和全量的信息需要的字段，另外加上版本，hash校验等。X
- 被推送端服务添加一个异步消息处理专用 View 来支持新版的消息推送。
- 在不需要顺序保证以及事务保证的时候允许发送端不发送 serial，由服务来处理 key。
- 队列中的消息无法被消费（不停的消费同一个消息）告警。
- 队列挂掉告警。
- 队列挂掉恢复之后自动重连及补发消息的功能。
- 通过记录发送端的 request_id 把异步各流程的日志串起来。
- 消除死锁报错。
- 对订单消息做一个案例示范。
P1 需求
P1的目标主要是让消息微服务支持更多的场景，把其他的异步使用慢慢并过来
- 添加一个预处理过程，把批量处理的异步任务分解成单独的小异步任务再逐个发出，这样可以将目前批量处理的异步的任务转成接口调用，方便部署和问题排查。
- 为了做到上面提到的特性，将发送消息那个接口做成异步的，因为有可能会比较耗时。
- 添加一个定期自动对老消息分表迁移的功能，目前消息表不断增大还无法方便的删除老数据。
- 支持非接口的异步调用，某些长耗时任务只能通过脚本执行的，使用协议区别，接口的以 http:// 开头，脚本的以 script:// 开头。
- 提供一个增加订阅配置的脚本或者接口。
P2 需求
P2的目标是在异步主体框架已经稳定的情况下做一些优化和小功能迭代
- 消息发送可以考虑支持定时发送和延时发送，这样后续可以根据用户使用情况做错峰，也可以统一定时任务的部署。
- 添加补推的时间算法，支持指数增加时间的推送方式。
- 支持多个 worker 同时消费队列。
- 支持自动检测订阅配置修改，更新订阅配置无需重启服务。
- 限制消息的大小。
- 提供提醒功能，在推送触发的时候发出提醒。